-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Refactor auto extension resolution to not use k6deps and esbuild #5320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
5c93d1d to
d738041
Compare
|
This likely should get more tests, and either drop the launcher.go and the old way or to further make it possible to use the old resolution method ... for now at least. But I would like some initial feedback and thoughts. |
internal/cmd/launcher.go
Outdated
| constraints := string(match[idxUseConstraints]) | ||
|
|
||
| if _, ok := deps[extension]; ok { | ||
| return deps, fmt.Errorf("already had a use directivce for %q", extension) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| return deps, fmt.Errorf("already had a use directivce for %q", extension) | |
| return deps, fmt.Errorf("already had a use directive for %q", extension) |
Is this printed to the user? Can we make it a bit more user friendly? I guess if this appears out of nowhere the user is not getting it fast.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see it now.
65afd95 to
c8e52fa
Compare
pablochacin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just gave a first pass and centered my comments on the structure of the code.
I find it unintuitive that we use an error for actually handling the missing dependencies. I would prefer if we could split the logic and use the error for reporting and let someone else (the root command?) to handle it by attempting binary provisioning.
Co-authored-by: Ivan <[email protected]>
38432f1 to
ca4a183
Compare
Co-authored-by: Théo Crevon <[email protected]>
| } | ||
|
|
||
| // TODO(@mstoykov) potentially figure out some less "exceptionl workflow" solution | ||
| type binaryIsNotSatisfyingDependenciesError struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| type binaryIsNotSatisfyingDependenciesError struct { | |
| type binaryUnsatisfiedDependenciesError struct { |
I don't want to block the pull request for it. But maybe in a another pr we should now align the error with the latest change.
What?
Reimplement auto extension resolution without using esbuild or k6deps, but the internal methods that k6 uses to load modules.
Why?
This removes the need for a separate project to have the same way to parse and understand imports and also double parsing everything.
Also fixing a number of bugs coming from this and removes the maintaince burden to keep both projects align.
Checklist
make check) and all pass.Checklist: Documentation (only for k6 maintainers and if relevant)
Please do not merge this PR until the following items are filled out.
Related PR(s)/Issue(s)
Based on #5240 and requires #5319 to have the same functionality as the same.
Fixes #5127
FIxes #5176
Fixes #5104
Closes #5102
Requirement for #5166 ( likely a future PR that refactors more of test_load.go)
Likely some updates to every other issue around automatic extension resolution as well.